Requirements engineering and management aims to aid the development of products or services in an industry and to the subsequent management of the products or services through their entire life-cycle. Computer implemented tools are known for use in requirements engineering which are intended to improve the requirements engineering process and thereby both the ultimate product or service, and the efficiency of their development.
The requirements engineering or management process typically involves determining the problem to be met and communicating the problem to the various relevant parties such as stakeholders, analyzing the requirements and determining the solution whilst taking into account the varying, often conflicting, needs of the relevant parties.
The process is often used in large scale engineering projects, for example those associated with aircraft development.
Commercially available software programs are available to help with the requirements engineering process. There are a number of problems with existing processes and tools. Such problems include the inclusion of a large number of duplications in particular where a large number of requirements are produced, which leads to increased cost. Furthermore known systems fail to produce a systematic method for re-using the requirements resulting in requirements that have had insufficient prior analysis and therefore are of low quality. Other problems include the maintenance of requirements traceability, the slow and/or laborious removal of duplications, the inefficiencies and slowness of the generation of requirements, difficulties in changing requirements, the difficulties and inconsistent ability to re-use requirements whether as part of the same product/service development or for use in a new development. Further existing systems give little guidance as to how close to completion the development process is and how many necessary or desirable stages of the requirements engineering process have been completed.
Some problems including some of those named above result from existing processes of requirements engineering whilst some result from deficiencies in existing computer implemented tools and others result from a combination of the processes and tools.
In the context of the aerospace industry, there are several different interested parties or “actors”, who may be spread across many different organizational sites, cultures, countries, time zones and languages. Such a global network is a highly complex network which typically has multiple layers of suppliers and contractors and risk sharing partners or stake holders whose requirements will need to be considered. In such large scale projects the long lead time, high costs and the highly complex nature of these products with very long lifecycles need to be considered, often resulting in a higher cost for the projects. Accordingly, in such situations the requirements of the system process and all actors must be considered in order to return an optimal solution. Furthermore, in such large scale projects there may be a high number of different requirements resulting in extensive duplication. These duplications further result in increased time and costs. Due to the lack of consideration when reusing previous requirements, the returned requirements are often of a lower quality. This further results in an increase in development time, the need to repeat the requirements engineering process, increase in overall project duration and further increase in costs. Yet another problem associated with prior tools and processes is that mutability of requirements is not explicitly allowed for. Any changes within the requirements in general lead to substantial corrective rework, i.e. repetition of parts of the requirements engineering process, and subsequent development processes such as the design and testing processes, resulting in significant delays, increased cost, and poor resource management.
At least some embodiments of the invention mitigate at least some of the above mentioned problems. In particular the provision of an ontological metamodel mitigates one or more of the above problems.
According to an aspect of the invention there is provided a computer system comprising a processor and memory, wherein the system is programmed to provide a metamodel comprising predefined fields relating to requirements engineering, and ontological relationships between the predefined fields, to receive an ontology relating to at least one domain or topic, to adapt one or more predefined field or ontological relationship based on the received ontology, and to prompt a user to enter information into the predefined fields in order to create a requirements specification and/or the steps for creating a requirements specification.
According to an aspect of the invention there is provide a computer system comprising a processor and memory, wherein the system is programmed to provide a metamodel comprising a plurality of predefined fields relating to requirements engineering, and (preferably ontological) relationships between at least some of the predefined fields, and to enable, and preferably to prompt, a user to enter information into the predefined fields in order to create a requirements specification and/or the steps for creating a requirements specification.
Preferably the metamodel comprises a plurality of templates for the creation of an instance, each template for an instance comprising at least two predefined fields. More preferably the metamodel comprises one or more (preferably predefined) class, at least one of (optionally each of) the classes comprising a template for the creation of at least one instance, the system programmed to enable/prompt a user to create a plurality of instances for each class using the template of that class. Two or more (or each) instances in a at least one (or each) class can contain at least two (or most/all) predefined fields which are the same/relate to the same aspects of requirements engineering and which are common to the template belonging to that class.
Preferably templates of at least two (or each) different classes contain at least one (or most/all) predefined fields which are different from each other and/or relate to different aspects of requirements engineering.
Preferably the metamodel comprises/defines at least one class comprising a plurality of sub classes, at least two sub classes having different templates for instances.
The metamodel may comprises one or more (and preferably a plurality of) hierarchies of classes comprising a parent class and child class, the system programmed to enable a user to create instances for each child class which is derived from an instance of a parent class.
Relationships can include one or more relationships between a field of a first template of a first class and at least a part of a second different class. More preferably the portion of a second class comprises a predefined field of a second template, which second template belongs to the second class.
The system can be programmed to enable/prompt a user to enter a reference to one or more of: a second instance and a completed predefined field of a second instance into a first predefined field of a first instance. Preferably the first and second instances are built from different templates/belong to different classes and/or the system is programmed to automatically enter information into a field in the second instance in response to the user entering the reference in the first predefined field of the first instance.
A plurality of classes may relate to roles of people involved in requirement engineering. One or more of the classes relating to roles can comprise a plurality of sub classes stating predefined roles and/or the class itself may state a predefined role.
Predefined roles can include one or more of: development team stakeholder, end user stakeholder, requirements engineer and ontology manager. Preferably wherein the user is enabled or prompted to create different numbers of instances for different roles.
A plurality of classes may relates to steps for creating a requirements specification. At least some of the classes that relates to steps for creating a requirements specification may comprise sub classes defining predefined workflows. Some of the predefined workflows may comprise sub classes defining predefined activities which each comprise a template for creation of instances.
A plurality of classes may relate to a solution space relating to a requirement specification. Preferably there are the parent and/or child classes of the class relating to a solution space which include one or more of: goals, soft goals and requirements. At least one (or each) template or some of the predefined fields of the at least one (or each) template of a requirements child class when completed by at least one user make up (at least part of) a requirement specification. At least one (or each) template for instances of a goal or soft goal can comprise a predefined field which has a relationship with a different template/class and for which a user is prompted to enter a reference to a specific (at least partially complete) instance of the requirement sub class which is derived from that instance of a goal or soft goal. Preferably goals are functional and soft goals are non-functional.
A plurality of classes may relate to a problem space relating to a requirement specification. Preferably at least some of the classes relating to a problem space comprise sub classes relating to needs of the requirement engineering. One or more (or each) template for instances of goals or soft goals can comprise a predefined field which has a relationship with a different template/class and for which a user is prompted to enter a reference to a specific (at least partially complete) instance of the need sub class from which that instance of goal is derived.
The predefined fields can be semantically linked within the metamodel by means of one or more of object and datatype properties. Preferably the property of the field constrains the type of information that a user can enter into that field and/or the property of the field constrains which instances can be referenced by a user in that field.
The system may be programmed to receive an ontology relating to at least one domain or topic, and to adapt one or more predefined field or ontological relationship based on the received ontology.
The computer system of one of the above mentioned aspects or a different computer system comprising a processor and a memory, may be programmed to use an at least partially completed requirements specification or requirement engineering steps (preferably created using a system of one of the above aspects) and is programmed to:
search instances for predefined fields that are empty or incomplete and display to a user a list of empty or incomplete fields, preferably providing navigational links to the empty or complete fields; and/or
search predefined fields of instances of one or more of needs, requirements and goals for duplications and to display to a user the results of the search; and/or search predefined fields of instances of one or more of needs, requirements and goals for conflicts and to display to a user the results of the search; and/or
automatically compile at least part of a requirements specification from information that a user has entered into a set of the predefined fields.
such that in response to the selection of an instance it presents one or more completed fields or summaries of instances that relate to the selected instance by using the relationships between fields in the metadata and information entered by the user into at least one field outside of the selected instance;
such that in response to the selection of an instance of a requirement it presents one or more completed fields or summaries of instances of a need or goal which it satisfies;
such that in response to the selection of an instance of a need it presents one or more completed fields or summaries of instances of a requirement or goal which are derived from it.
According to an aspect of the invention there is provided a computer enabled method, the method comprising the steps of: populating a metamodel comprising a plurality of predefined fields relating to requirements engineering, and (ontological) relationships between at least some of the predefined fields, and creating a requirements specification and/or the steps for creating a requirements specification using the metamodel.
According to an aspect of the invention there is provided a computer enabled method, the method comprising the steps of: searching an at least partially completed metamodel for desired results, the metamodel comprising a plurality of predefined fields relating to requirements engineering, and (ontological) relationships between at least some of the predefined fields, and presenting desired results in the form of information that has been populated in the predefined fields by using the relationships between some of the predefined fields to present.
The method(s) may include any step(s) corresponding to any of the feature described above in relation to a computer system in accordance with an aspect of the invention.
Other aims and aspects of the invention will become apparent from the appended claim set.